[iOSDC Japan 2019 リポート] 画像リサイズの話とダンボーさん(元・弊ブログ中の人)のエモ話!

はじめに

CX事業本部の中安です。

東京・早稲田大学構内で行われている「iOSDC Japan 2019」に参加をさせていただいています。

3日間に渡るこのイベントを、弊社iOSアプリ開発メンバーと一緒に色々とレポートしていければと思います。

ここまでのおさらい

• [iOSDC Japan 2019 リポート] iOSDCの前夜祭に参加してきました!!
• [iOSDC Japan 2019 リポート] 午前セッション! 色と視覚についての知見を得てきた!
• [iOSDC Japan 2019 リポート] iOSアプリ開発者だらけのアンケート! ブースレポ | DevelopersIO

「画像処理における、UIImageとCGImageとCIImageの効果的な使い分け」

Sansanの栗山さんによる「画像処理における、UIImageとCGImageとCIImageの効果的な使い分け」を聞いてきました。

UIImage、CGImage、そしてCIImageは、いずれも画像情報を保持するためのクラス(以下、画像クラス)ですが、皆さんはこの3つのクラスの特徴を理解して使っていますか？

Web APIで取得した画像を縮小して表示できればよい、といった単純な要件であれば、何も考えずにUIImageを使うだけでも済みますが、リアルタイム処理や複雑な画像処理などのより高度な要件においては、特徴を知らずに使ってしまうと余計な処理を書いてしまって最悪性能低下を招くことになってしまいます。

本セッションでは、UIImage / CGImage / CIImageの各画像クラスの特徴を解説しながら、これら3つのクラスの画像処理における使いどころについてご紹介します。

また、OpenCVなどの画像処理ライブラリとの連携を考慮した画像クラスの使い方や、私が業務で実際に画像処理の性能改善に成功したエピソードもご紹介します。

本セッションが普段何気なく使っている画像クラスについて改めて考えるきっかけとなれば幸いです。

内容と感想

名刺管理サービスとして有名なSansanさんのアプリでは、OCR技術の他にOpenCVを使用してのエッジ検出を行っているようです。 その際にはカメラからインプットされた画像データを素早く処理しなければならないとのことです。

CVにおいてのデータとUIImageの互換のためにCImage(Core Image)を介して行いますが、 その中間の処理のベンチマークについて具体的なソースを交えてのお話でした。

自分も昔にOpenCVで輪郭検出して近しいことをやってたので懐かしい感想を得ました。

しかしながら、CIImageの特長などをそれほど深くは理解していなかったので、そのあたり少し解説いただいてよかったです。 (わがままをいうと、もうすこしCIとCGの違いについても聞きたかったです)

最後のほうにUIGraphicsImageRendererと旧来のImageContextとのベンチ比較の話もありました。 画像のリサイズ処理では UIGraphicsImageRenderer のほうが時間がかかるというお話でしたが、 もしかしたらスレッドあたりの工夫で早くなるかもなーと思いました。

UIGraphicsImageRendererについては、弊ブログも過去に書いてるようなので参考になさってください

[iOS 10] UIGraphicsImageRenderer について

元クラメソメンバーによるテストとの試行錯誤 「FatViewControllerを安全に書き換える方法が見つからなかったので、どういう痛みを許容するか考えた」

同じ職場の元仲間でダンボー田中氏ことタナケンさんよる 「FatViewControllerを安全に書き換える方法が見つからなかったので、どういう痛みを許容するか考えた」という発表を聞きました。

そのうちスライドはあがる気がする・・・。(やっぱり未だにブログは「こんぬづは」で始まるんですね)

iOSDC Japan 2019で『FatViewControllerを安全に書き換える方法が見つからなかったので(ry』という発表をします #iosdc - ?田中、仙台に生きる? https://t.co/jQpi9OR72n

よろしく〜?

— ダンボー田中? (@ktanaka117) September 5, 2019

スライドあがってました

安全にリファクタリングを行うには「お約束」があります。

「自動テストを書いてからリファクタリングする」

言葉にしてしまえば簡単で「プログラマであれば当然のことだ」とおっしゃる方もいらっしゃるかもしれません。 でもそれを難しくするのがヤツの存在です。そう、iOSエンジニアならば切っても切れない関係のFatViewControllerです。

前述のお約束を守るために、こんな堂々巡りに陥ったことのある方は少なくないのではないでしょうか。 ・「UIテストを書いた上で書き換えを行うか？」「時間がかかりすぎる、ダメだ...！」 ・「ユニットテストを充実させて設計を変更しながら書き換えを行うか？」「先にプロダクトコードの変更が発生してしまう、ダメだ...！」

このトークではFatViewControllerの書き換えを「自動テストを書いてから」というお約束を守ってこなすのが難しかった話をします。 そのうえでなるべく安全に、現実的に書き換えていく方法にはどんなものがあったか、どんな部分で安全を切り捨てて痛みに耐える判断をしたのか話をします。

内容と感想

タナケンさんのお話は本人も話していましたが、登壇の内容は「これが正解ですよ」という内容ではなく、起きた問題を具体的で客観的に見つめ直して試行錯誤した感がすごく伝わってくる内容でしたね。

テストの導入とその手法の選択には、シチュエーションとナレッジ、ステークホルダーとの合意形成など、前にこれが成功したからといって次もこれで成功するものではないという当たり前のことを考えさせられました。

最後のまとめの話にあったのですが 「最低限なことができてないの?って思われるかも知れないけど、最低限ができてなければ、最低限ができれば偉いって話」ていうのが個人的にはエモくて良かったです

彼のプログはまだDevelopers.IOに沢山残ってますので、ご興味のある方はぜひ

まとめ

ロングセッションは本日はこれでおしまい。LTも最後まで楽しみますー

では、また